Use per-project Sentry configuration #4818
Open
+31
−8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MiSikora
added
the
[Type] Tooling
MiSikora
commented
Dec 3, 2025
| autoInstallation.enabled = false | ||
| includeDependenciesReport = false | ||
| ignoredBuildTypes = setOf("debug", "debugProd") | ||
| ignoredBuildTypes = setOf("debug", "debugProd", "prototype") |
Contributor
Author
There was a problem hiding this comment.
This is an unrelated change but I forgot to exclude prototype builds from Sentry uploads.
Collaborator
Generated by 🚫 Danger |
Copilot finished reviewing on behalf of
MiSikora
December 3, 2025 08:55
Contributor
There was a problem hiding this comment.
Pull request overview
This PR migrates Sentry configuration from a single sentry.properties file to per-project Gradle configuration, enabling separate Sentry projects for Android, Automotive, and Wear applications.
Key Changes
- Added Sentry configuration properties (auth token, org, and project names) to
dependencies.gradle.kts - Configured project-specific Sentry project names in each application module's build file
- Renamed
configureSentry()toapplyCommonSentryConfiguration()and added auth token and org configuration - Added "prototype" to ignored build types for Sentry uploads
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| dependencies.gradle.kts | Adds five new Sentry-related properties from secret properties: auth token, org, and three project names |
| build.gradle.kts | Renames Sentry configuration function, adds auth token and org properties, includes "prototype" in ignored build types, removes unused import |
| app/build.gradle.kts | Configures Android project-specific Sentry project name |
| automotive/build.gradle.kts | Configures Automotive project-specific Sentry project name |
| wear/build.gradle.kts | Configures Wear project-specific Sentry project name |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Currently, our builds upload data to our main Android Sentry project. Since we decided to split Android, Automotive, and Wear apps into separate ones, this now needs to be handled in the build system.
Our Sentry configuration is stored in the
sentry.propertiesfile. However, this file lives in the root project. I wasn’t able to find anything in the Sentry documentation indicating whether it’s possible to have multiple such files one in each sub-project or to define per-project properties within the root file.To address this, I propose configuring everything through the Gradle plugin. This change will need to be accompanied by an update to the
mobile-secretsrepo to add the necessary properties. I can do it once we agree on the approach and sync the modifications in both repositories.Relates to: https://linear.app/a8c/issue/AINFRA-1610/
Testing Instructions
I'm not sure if it is possible to test it really until we create a release build. But if anyone has an idea I'd like to know.